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ABSTRACT 


In recent decades, the networking community has been looking for strategies to 
converge over a single common network infrastructure carrying voice, video and data. 
The pervasive and ubiquitous packet-based ff network provides the most convenient 
platform for the desirable convergence, where resources can be managed in an efficient 
and dynamic manner. 

The gradual convergence into the EP infrastructure introduces multimedia-rich and 
interactive applications that are bandwidth-intensive and delay-bound, while more 
sophisticated data applications are deployed that place new demands onto IP networks. 
The ff-based network is evolving to satisfy the requirements of traffic differentiation and 
reliable service. Quality of Service (QoS) mechanisms are introduced to meet the traffic 
expectations and enhance the basic service model of the network in many subtle ways. 

This thesis provides a comprehensive examination of QoS mechanisms and 
protocols that have surfaced to optimize the utilization of network resources, to provide 
differentiated treatment of traffic and enforce the appropriate policies. The study 
proposes a balanced approach of bandwidth increase and integration of robust QoS 
techniques into existing IP network infrastructure to arrive at a convergent, multiservice 
and scalable telecommunications network. Findings from this thesis can be incorporated 
into the design and implementation of an integrated network within a large organization 
that will deliver accurate services and defined level of performances. 
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I. INTRODUCTION 


A. NETWORKS OF THE 1990S 

Traditional voice networks are circuit-switching networks that are built to provide 
an optimal service for time-sensitive voice conversation, requiring low delay, low delay 
variation Cider), and constant but low bandwidth of 3 KHz in analog form and 64 Kbps 
in digital form. A key characteristic of such networks is that resources are dedicated to a 
particular connection for the entire duration. This approach is nice for the users, but fails 
to utilize efficiently the limited network resomces. Additionally, these networks do not 
provide the high bandwidth requirements for video and high-speed data traffic. 


The data networks and the Internet, based on a connectionless packet-switching 
scheme, accomplish a more robust and dynamic handling of resources. The TCP/IP 
protocol suite, which lies at the heart of public and private data networks, was designed 
to provide a best-effort service model for the data applications. It is this model that 
allowed the IP-based data networks to grow exponentially; this also led to a network 
infrastructure that falls short of delivering tight performance guarantees needed for delay- 
sensitive commimication. 


A third type of networks is the cable TV network deployed over coaxial wiring 
scheme that can deliver much higher bandwidth up to 36 Mbps [Ref. 1], through cable 
modems. This network was designed and optimized to carry TV signals to users’ 
premises in the downstream direction only. To carry interactive voice and data, proper 
switching equipment is installed that permits bi-directional communication across the 
cable. 


The recent decades, the networking community has been looking for strategies to 
converge over a single common network infrastructure carrying voice, video and data. 
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Since the mid-1980s, the need for a universal packet-based network has been identified, 
where resources can be managed in a more efficient and dynamic manner. After several 
convergence efforts, it appears that the pervasive and ubiquitous IP-based data network 
will provide the common denominator and the most convenient platform for the desirable 
convergence. 


The gradual convergence into the IP infrastructure introduces multimedia-rich and 
interactive applications that are bandwidth-intensive and delay-bound. Additionally, more 
sophisticated data applications are deployed that place new demands onto IP networks. It 
is not only the introduction of a greater volume of traffic, but also a greater diversity of 
traffic characteristics. Not all of the streams are equally important. Each presents imique 
performance requirements, but all expect an excellent network service. While these 
requirements can be quantified using several criteria that incorporate performance, 
availability, reliability, and security, in the context of this thesis, they are defined in terms 
of data rate, delay, jitter, and packet loss. The IP-based network is evolving to satisfy the 
requirements of traffic differentiation. Quality of Service (QoS) mechanisms are 
introduced to meet the traffic expectations and enhance the basic service model of the 
network in many subtle ways, enabling the reliable and predictable service to 
differentiated network traffic. 


Delivering QoS in a multiservice and convergent IP-based network presents 
several challenges. These challenges require a clear imderstanding of the current network 
environment, analysis of existing and emerging technologies, potential upgrade of the 
infrastructure and efficient implementation of flexible mechanisms that can deliver the 
desired QoS to overcome current performance deficiencies. 

B. RECENT ADVANCES IN QUALITY OF SERVICE 

The need for QoS deployment in IP network has brought a lot of attention in 
recent years. Research and education communities have perceived the importance of the 
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current and future sustainability of the IP-based networks. The U.S. government imder 
the Next Generation Internet (NGI) is playing a key role in supporting research and 
development of high-performance network technologies and services. 


The Internet n project, led by the private sector and universities, runs in parallel 
with the federal NGI initiative. One of the most important studies in the Internet n project 
is on the QoS. The two projects stress the necessity of network resource allocation and 
management for different kinds of applications. 

From the standards perspective, Internet Engineering Task Force (IETF), the 
principal body engaged in the development of new Internet standard specifications, is 
actively embracing the issues around QoS, especially the “Operations and Management 
Area” working group. Recent work in the IETF has led to the development of several 
standards for a QoS-enabled network. 


The networking industry, reacting to the growing demand of enterprises that 
struggle with the issue of how best to ensure that applications receive the service quality 
that they require, has already begtm to put QoS technologies into practice. 


C. OBJECTIVE 

The objective of this thesis is to investigate the methods of deploying QoS in IP- 
based networks, identify key issues of QoS implementation and propose a robust QoS 
deployment that will allow a imified convergent IP-based network to provide reliable, 
consistent and guaranteed service in a plethora of applications within an organization. 


D. ASSUMPTIONS AND LIMITATIONS 

This thesis attempts to describe the ongoing effort for improvement of the IP 
network infrastructure, to explore proposed mechanisms and evaluate enhanced service 
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models. The findings reported will provide the reader with an understanding of key 
technologies and techniques that enable QoS and traffic management. Because these are 
relatively new developments, they need to be brought to the attention of the reader to help 
him better evaluate existing IP network design and operation and determine how to 
improve upon traditional best-effort service. 


The author assumes the reader has a basic understanding of fimdamental 
networking principles, models and devices. A thorough presentation of all issues related 
with QoS in IP networks entails employment of a great deal of technical detail, but a 
systematic effort has been made to present the topic in a simple and clear manner. 


Given the breadth of the topic, the scope of this study is limited to QoS in a large 
private network. This large network can consist of the following three components: 

• Campus networks, which connect a building or group of buildings with 
one or more Local Access Network (LAN) and backbone connections. 

• Wide Area networks (WAN), which connect campuses together and may 
also include radio-WANs that reach to mobile platforms such as ships, 
which increasingly have campus networks within. 

• Remote connections that link remote offices, vmits and users to a central 
location or campus. 


This enables a comprehensive and holistic analysis of QoS that meets the needs of 
a large organization, whose QoS-enabled multiservice network can support 
strategic/tactical operations, rapid access to information, effective decision making, 
efficient data distribution and knowledge management. 
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E. ORGANIZATION OF THESIS 


In Chapter H, a first task is to analyze the nature of IP-based and voice networks. 
Then, the trend for convergence of voice and data networks into an IP infrastructure is 
examined and the needs of differentiated traffic are analyzed. 


In Chapter EH, QoS is defined and effective QoS mechanisms and techniques are 
examined that provide prioritization, signaling, congestion control and policing in the IP- 
based network. 


In Chapter IV, the study provides a solid explanation and evaluation of the QoS 
service models that have been developed to integrate all the QoS mechanisms in a 
network-wide implementation. 


In Chapter V, an integrated end-to-end QoS deployment is proposed that is 
essentially a balanced approach of bandwidth increase and QoS implementation with 
minimal overhead and change to the stateless and connectionless nature of the IP 
network, providing the necessary efficiency and dynamic traffic management. Several 
current commercial solutions are also examined. 


In Chapter VI, conclusions, recommendations and suggested topics for further 
study are discussed. 
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II. CONVERGENCE OF IP-BASED AND VOICE NETWORKS 


The purpose of this chapter is to analyze the nature of IP-based and voice 
networks, examine the trend of converging these two networks and understand the 
requirements imposed in the integrated network by different voice, video and data 
applications. First, it is necessary to define the network metrics used to measure the 
performance of the network. 


A. NETWORK PERFORMANCE METRICS 

The way in which any network handles traffic can be characterized through a set 
of metrics. These parameters provide a quantitative picture of the traffic performance in 
the network and in the context of this thesis, the following metrics have been specified: 

• Data rate (bandwidth) is the raw data carrying capacity of a network. It is 
the rate at which traffic is carried by the network from one host to another 
and is usually measured in bits per second. 

• Delay (latency) is the amount of time it takes the network to deliver a 
packet to its destination and is often measured in milliseconds. While it is 
very small in voice networks, the majority of the end-to-end delay in data 
networks is attributed to the switching delay that is introduced by the 
networking devices. 

• Jitter (delay variation) is a term used to describe the variation in arrival 
times to the destination for different packets and is measmed in 
milliseconds. Jitter is particularly disruptive to voice and video 
communications that require transmissions at a constant rate. Receiving 
devices compensate for jitter by setting up local buffers to playback voice 
and smooth out variability in packet arrival times. There is a tradeoff 
though because the use of buffering increases latency. Jitter is mainly 
introduced in the packet switching networks and is due to the different 
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paths that packets may follow and different queuing times packets 
experience in the internetworking devices. 

Packet loss is measured in terms of the percentage of the total packets 
sent. Data applications, such as file transfers, are very sensitive to packet 
loss, while voice and video applications allow a certain percentage of 
packet loss. Packet loss may occur because of network link failures, 
introduction of noise in wireless and RF networks and in packet networks, 
in case of congestion, the network devices fill up and start discarding 
packets. 


Based on these metrics, the requirements of voice, video and data traffic are 
summarized below in Figure 1. 


Application 

Bandwidth 

Delay 

Jitter 

Packet 

loss 

Interactive Voice 

Low 

5-64 Kbps 

200 ms 

30 ms 

1 % 

Interactive Video 

Medium - High 

400 ms 

30 ms 

5% 

Data 

Adaptive 

Seconds 

Minutes 

Allowed 

0 % 


Figure 1. Requirements of Voice, Video and Data Traffic. 


B. THE NATURE OF IP-BASED DATA NETWORK 

IP-based networks were designed to support data applications that are 
characterized by bursty traffic with occasional high bandwidth demand and longer delays. 
These data applications are consolidated over a packet-switching network, built around 
network devices, such as routers, switches, bridges and hubs as shown in Figure 2. 
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Figure 2. Data Network Infrastructure 

1. Internet Protocol 

The rapid adaptation of the TCP/IP protocol suite in the enterprise intranets and 
the global Internet has resulted in the indisputable dominance of Internet Protocol (IP) as 
the most widely used internetworking protocol. IP represents the third conceptual layer of 
the TCP/IP protocol suite, shown in Figure 1, and has provided a consistent service 
interface that has remitted the relatively independent development of applications and 
underlying networking technology. 


IP provides a connectionless service between end systems, routing packets from 
network to network. It specifies the format of packets sent across the network as well as 
the mechanisms to forward packets. Currently, the most widely deployed version of this 
protocol is version 4 (IPv4). However, an enhanced version (IPv6) has been standardized 
and is ready for deployment. 


9 
















D ata, V oice. 
Video 

A pplication 

- Layer 5 




TCP, UDP 

T ransport 

- Layer 4 




IP 

Internet 

- Layer 3 




Ethernet, ATM, 

T oken Ring, FDD I, 
Frame Relay 
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Figure 3. Layers of TCP/IP Protocol Suite. 


2. Transport Protocols 

The transport protocols provide the basic end-to-end service of transferring data 
between end hosts. They are the interfaces between the internet and the application layer. 
The TCP/IP protocol suite includes two transport protocols, the Transmission Control 
Protocol (TCP), which is connection oriented, and the User Datagram Protocol (UDP), 
which is connectionless. 


TCP is a connection-oriented protocol and is responsible for the reliable, in-order 
delivery of a stream of data. Since IP is a connectionless protocol that makes no effort to 
correct transmission errors, TCP is deployed to guarantee that the stream of data leaving 
the sender will be reassembled intact at the receiver end. It accomplishes that through a 
system of delivery acknowledgements. It is also responsive to packet loss allowing 
efficient retransmission of lost information. 


TCP is designed to be adaptive to data rates allowed by the network. A TCP 
sender constantly adjusts itself based on the current level of network performance and 

introduces traffic into the network accordingly. When the TCP sender determines that a 
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packet did not make it through the network, it slows the transmission rate. These features 
make TCP a very reliable protocol, but also a source of overhead for the network. 


In contrast to the adaptive, error correcting nature of TCP, UDP is a 
connectionless transport protocol that makes no effort to guarantee delivery and does not 
adapt to network congestion. It sacrifices these in return for no setup overhead, no 
acknowledgement and sequencing of traffic. Because it is connectionless, UDP has very 
little to do and essentially it only adds a port addressing capability to IP. 

3. Connectionless and Stateless Nature 

The P-based network is connectionless and stateless because the P protocol by 
nature is a connectionless protocol. The minimal function required from the network is 
mere connectivity; that is delivery of datagrams from a source to a destination. There are 
no predefined circuits or fixed paths among the network devices and the end nodes. TCP 
is normally used for setting up a confirmed coimection between two communicating end 
hosts, but networking devices along the path never look this deep into the passing packets 
that they route. This principle allows complexity to stay in the end-hosts, so the network 
can remain relatively simple. 


The term stateless means the nodes along the path of the traffic flow do not 
maintain specific information about the state of each flow. Each datagram is treated 
independently and equally, with no reference to datagrams that have been processed 
before. The routers maintain routing tables and forward datagrams according to these 
tables without keeping track of whether a particular datagram is part of several in a flow 
from one node to another. Successive datagrams of the same flow may follow entirely 
different routes to the same destination. 
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Given knowledge of the ultimate destination of a datagram, the network finds, if 
possible, a path through any available links to the destination. If network failures or 
congestions occur (created by lack of resources), there is unpredictable response from the 
network (a datagram may be delayed, duplicated or discarded). There are no guarantees 
that any given packet will reach its destination at all and the time it takes the network to 
achieve packet delivery is a secondary consideration and heavily depends on the 
switching delay introduced in the networking devices. Essentially, the packet-switching 
IP-based network is a network of queues that uses a “store-and-forward” approach. An 
arriving packet is placed in the queue of a networking device until the processor of the 
device can process and forward the packet to its destination. The processing of a packet 
may include several steps, such as looking up the routing table, deciding for the correct 
forwarding interface and manipulating the packet (changing the encapsulation type, 
changing the hop count). Furthermore, as more traffic is introduced to the network, 
service demands eventually exceed resources. Nevertheless, the network does not deny 
service, but instead it degrades its performance gracefully. This service model is called 
best effort because, although the network makes every effort to deliver datagrams, it 
makes no guarantees. 


This scheme has led in part to the success of the IP-based network and the 
Internet, providing increased flexibility, resource sharing, robustness, responsiveness and 
scalability. Nevertheless, it does not guarantee a bounded service with respect to 
timeliness and preservation of temporal ordering. The IP network focuses more on 
“where” to send datagrams and little on the “when”[Ref. 2]. 


C. THE NATURE OF VOICE NETWORKS 
1. General 

Traditional voice and telephone networks are built to provide an optimal service 
for time-sensitive voice applications requiring low delay, low jitter and constant but low 
bandwidth of 3 KHz in analog form and 64 Kbps in digital form.. These networks are 
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built in a connection-oriented and circuit-switched approach. Communication is achieved 
by dedicating a communication channel, which is set up prior to information transfer, for 
the duration of the connection between two nodes. 


Initially, analog transmission was used for the transfer of voice. But gradually, the 
voice network is migrating to digital transmission using pulse code modulation (PCM) or 
adaptive differential pulse code modulation (ADPCM). In both cases, analog voice signal 
is converted into digital form by sampling the analog signal 8000 times per second and 
converting each sample into a numeric code. That results in a data rate of 64 Kbps for a 
digital voice channel that has been standardized throughout the world. 

2. Structure 

a. Public Switched Telephone Network 

Public Switched Telephone Network (PSTN) is the global telephone voice 
network and represents the collection of the switching and networking equipment that 
belongs to carriers who provide telephone services. It refers primarily to the wireline 
telephone network and its access points to wireless networks, such as cellular and satellite 
communications. The basic hardware elements of the PSTN are telephone sets, premises 
wiring, local exchange switches, interexchange carrier switches and trunks between 
switches [Ref. 3]. The PSTN distinguishes between 

• Access lines (also called local loop) that connect telephone sets to local 
switches. 

• Trunking networks that multiplex voice channels between voice switches 
for long distance access. 

The access line is typically a single pair of twisted-pair copper wires, 
while the backbone trunking network can be carried on coaxial cable, fiber optic cable or 
microwave towers. 
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In organizations, the telephone devices are anchored around a voice 
switch, named Private Branch Exchange (PBX), as illustrated in Figure 4, that is used to 
interconnect telephones within a building and enable connection into PSTN infrastructure 
or a dedicated leased line for private use. The links from the PBX to individual 
telephones are access lines, where voice exists either in analog or digital form, and from 
the PBX to the central office are direct trunks that carry voice in digital form. Once voice 
reaches the central office, it exists in digital form on the network, on time division 
multiplexed channels of 64 Kbps each. 



Figure 4. PSTN Infrastructure. 


b. Wireless Networks 

Electromagnetic radiation can also be used to transmit information. 

Cellular networks are deployed extensively to support voice communications. These 

networks do not require a direct physical connection between users. Each participating 

unit attaches to an antenna, which can both transmit and receive RF. Base stations 

communicate through radio signals with end users. RF technology can be combined with 
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satellites to provide communication across longer distances. The wireless networks 
present difficulties inherent in wireless media, such as interference and limited capacity. 

3. Observations 

In voice networks, the quality of a call has never been a negotiable parameter. 
However, delivering this quality comes at a cost because the circuit-switched nature of 
the network ties up network resources for the duration of an entire call, regardless of the 
actual bandwidth utilized [Ref 4]. 


Furthermore, the whole network has been originally designed and implemented to 
support small, fixed-bandwidth needs in increments of 64Kbps. Data can be transmitted 
by the use of proper dialup modems. Although technologies like Integrated Services 
Digital Network (ISDN) and Digital Subscriber Loop (DSL) allow the transmission of 
data at higher data rates, the inherent limitations of the twisted pair wiring places upper 
bounds to the rates at which data can be sent. 


Voice networks achieved their dominant position because they were well suited to 
the analog and digital transmission of voice signals. However, their connection-oriented 
nature and their support for relatively low bandwidth does not make them well suited 
today with the increased need for high-speed digital access and the expansion of intensive 
data and video applications. 

D. THE TREND FOR CONVERGENCE IN IP-BASED NETWORK 

The recent decades, the networking community has been looking for strategies to 
merge the two different networks over a single common network infrastructure carrying 
voice, video and data. Since the mid-1980s, it has been viewed as necessary to replace the 
TDM public network with a universal packet-based network, where resources can be 
managed in a more efficient and dynamic manner. After several convergence efforts 
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(ISDN, ATM), it appears that the industry has landed on a common platform of the IP- 
based network. The irresistible logic is that digitized voice and video is just another kind 
of packet data that can be handled by the ff network in a robust and bandwidth efficient 
manner. IP s pervasiveness and ubiquity in personal computers, servers, workstations, 
routers and switches makes it the common denominator and the most convenient platform 
for the support of integrated traffic. 


Using a converged network, an organization with geographically dispersed offices 
and units can reap the following benefits: 

• Reduce operating costs by eliminating redundant hardware and wiring 
required to support separate voice and data infrastructures. 

• Enable rapid access to information and effective decision-making. 

• Increase network manageability and interoperability. 

• Enhance productivity, mobility and efficiency. 


Converged IP networks could also enable new compelling applications, such as 
multimedia call centers that integrate customer messages coming in any format - 
telephone, fax, paging, voice mail, or e-mail - into a single, centralized and unified 
messaging system. Other applications that can take advantage of the convergence are 
distance learning, powerful collaboration tools, integrated directory services and device 
portability with user ID services. 


The merger of voice, video, and data networking is in the early stages of adoption 
today. Applications, such as Voice over IP (VoIP) and desktop video conferencing that 
take advantage of these converged communications capabilities have appeared in large 
organizations. Packetized voice and video is on the rise in the WAN access, successfully 
bypassing expensive long-haul PSTN connections, as illustrated in Figure 5. 
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Figure 5. Bypassing Long-Haul PSTN Connections Using IP WAN Access. 


Organizations take incremental steps towards an integrated, multiservice network: 

• Upgrade to an IP-enabled PBX. This upgrade can be done to the existing 
traditional PBX inside the organization and essentially involves only the 
addition of IP line cards with LAN interfaces to a PBX. 

• Introduction of IP Gateway that bridges the gap between the IP data 
network and PSTN, allowing voice calls to traverse voice and data 
networks seamlessly. 

• Introduction of IP Gatekeeper on the IP network that provides call 
functionality, address translation, admission control and bandwidth 
allocation. 

• Introduction of call servers that perform voice-related applications, such as 
voicemail. 

The IP-based convergent network, as shown in figure 6, is increasingly being 
adopted in new facilities and offices, where there are no legacy systems to amortize. 
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Figure 6. End-to-End Converged IP Network. 


E. APPLICATIONS REQUIREMENTS 

The gradual integration of voice and video in IP networks, the emergence of new 
applications and the increased sophistication of existing ones have forced the ff network 
to carry traffic with diverse requirements. Traditional applications, such as e-mail, file 
transfer and web browsing and emerging ones, such as voice over IP, desktop video- 
conferencing, live or on demand streaming media, all compete for network resources. 
They generate traffic at varying rates and expect the network to handle it in an 
appropriate and sufficient way. 


This evolution places new demands onto the IP infrastructure. The network is 
expected to accommodate all these applications and provide reliable and deterministic 
service to the various traffic types. Therefore, the basic service model of the network 
must be enhanced in many subtle ways to achieve the required performance guarantees. 
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It is important to understand the requirements of the various applications in order 
to function correctly. These requirements are expressed using the quantifiable network 
parameters that have been defined earlier in this chapter and include bandwidth, delay, 
jitter and packet loss. For some applications, there is always a need for fixed bandwidth, 
others adapt to consume the maximum available bandwidth, and for others it may vary 
with time. Certain applications are more or less tolerant of traffic delays in the network 
and of variation in delay. Other applications can tolerate some degree of traffic loss while 
others cannot. 


1. Elastic / Inelastic Applications 

There are a number of categories imder which application traffic may fall, 
depending on how tolerant or intolerant the application is to network congestion and 
other inconsistent network behavior. Broadly speaking, the two fundamentally different 
traffic types on datagram networks are elastic and inelastic traffic [Ref 5]. 


Elastic traffic originates from applications that run on top of TCP, such as HTTP, 
FTP and SMTP and can be described as data applications. They always wait for all data 
to arrive and TCP provides the required reliability and adaptability. Services that run in 
the background without any user interaction are also typically elastic, such as network 
services (routing tables updates, network management). 


On the other hand, inelastic applications need to have their data communicated in 
a deterministic and consistent manner. Such time-sensitive data must arrive at its 
destination on schedule or within a boimded delay. There are further subdivided into 
tolerant and intolerant, based on the way they react to delay. Inelastic tolerant 
applications, such as streaming media and video-on-demand do expect their data to arrive 
in a timely fashion, but they do not impose serious timing constraints. Occasional delayed 
packets do not cause unacceptable operation. The intolerant applications, such as 
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interactive voice, are the most demanding and have tight timing constraints. If their 
traffic is not handled consistently and precisely at all times, they degrade unacceptably. 

2. Voice Considerations 

a. Digitization and Compression 

The irresistible logic is that digitized voice and video is just another kind 
of packet data. Several coding schemes have been developed that compress speech by 
sending only simplified information about voice transmission; reducing the required 
bandwidth [Ref. 6]. Essentially, compression is a balancing act between voice quality, 
local computation power, delay, and network bandwidth required. The greater the 
bandwidth reduction, the higher the computational cost and delay for a given level of 
perceived clarity. 

Coding techniques are standardized by the ITU-T in its G-series 
recommendations. The most popular coding standards for telephony and voice packet are: 

• G.711, which describes the 64-kbps PCM voice coding technique used in 
PSTN 

• G.723.1, which describes a compression technique that can be used for 
compressing speech or audio signal components at a very low bit rate. It 
has two bit rates associated with it: 6.3 and 5.3 kbps. 

• G.726—Describes ADPCM coding at 32 kbps. ADPCM-encoded voice 
can be interchanged between packet voice, PSTN, and PBX networks if 
the PBX networks are configured to support ADPCM. 

• G.728, which describes 16-kbps low-delay voice compression. 

• G.729, which describes voice compression into 8-kbps streams. 
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b. Compression Delay 

One of the most important design considerations in implementing 
interactive voice is minimizing one-way, end-to-end delay. For human requirements, an 
acceptable one-way delay for a voice conversation (mouth-to-ear delay) is approximately 
150 milliseconds, while toll quality is achieved when the delay is less than 100 ms [Ref. 
7] and [Ref 8]. Apart from the delay imposed by the network, specifically for voice, 
compression delay must also be considered. It is the delay induced by the devices that 
handle voice information. Figure 7 shows the bit rate and the compression delay 
introduced by different coding schemes. 


CODEC 

Bit Rate 
(kbps) 

Payload Size 
(bytes) 

Compression Delay 
(ms) 

G.711 PCM 

64 

160 

0.75 

G.726 ADPCM 

32 

80 

1 

G.728 

16 

40 

3 to 5 

G.729 

8 

20 

10 

wmJkmAMiM 

6.3 

30 

30 1 


5.3 

30 

30 


Figure 7. Bit Rates, Payload Sizes and Delays Induced By Coding Schemes. 


c. Packet size 

Packet size is also a key issue that must be taken into account in a network 
that will accommodate voice traffic. Data achieves maximum throughput when packet 
sizes are large, minimizing the overhead of the headers. However, voice cannot use such 
large packets because it will introduce extreme handling delays and additional echo 
problem. Furthermore, if a packet is lost in the network, the small packet is less likely to 
contain significant parts of a speech signal. The packet size was a big issue in 
standardization of ATM cell size that was eventually agreed in 53 bytes. The payload 
sizes of voice packets vary from 20-160 bytes based on the coding scheme that is used to 
generate the packet, as shown in previous figure 6. 
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d. Real-Time Transport Protocol (RTP) / Real-Time Control 
Transport Protocol (RTCP) 

The transport of voice and video on IP-based networks requires the 
existence of a protocol that can provide a notion of time network-wide and allow control 
over jitter, desequencing and delay. Real-time Transport Protocol (RTP) was developed 
from IETF to fulfill this gap and is now being used as the core protocol for transport of 
inelastic applications. Its primary role is to act as a simple, functional and scaleable 
interface between inelastic applications and existing transport layer protocols. It is 
described in RFC 1889 specification as being a thin protocol providing support for 
applications with time sensitive properties, including timing reconstruction, loss 
detection, security and content identification. While its specification does not dictate 
which of the underlying transport and network layer to use, typically it is utilized on top 
of UDP/IP as shown in Figure 8. 



Figure 8. RTP / RTCP Protocols. 


RTP is used to send data in one direction with no acknowledgement, but 
with an inherent notion of time. This allows receivers to compensate for the jitter and 
desequencing introduced by IP-based networks. RTP adds a new 12-byte header on top of 
UDP/IP headers to describe each datagram. This header contains: 

• Time stamp, so the recipient can reconstruct the timing of the original 
data. This timestamp contains relative timing information that represents 


22 






timing relations between packets, not absolute points in time. Therefore, 
sender and receiver do not need to be synchronized. 

Sequence number, which lets the recipient reassemble the data and deal 
with missing, duplicate or out-of-order datagrams. 

Payload type, which describes the type of data, such as voice, audio or 
video and how it is encoded and compressed. 

Source ID, which helps a recipient distinguish multiple, simultaneous 
streams, using a unique sender-generated value. 


The functionality of RTP is enhanced with another protocol called the 
Real Time Control Protocol (RTCP), which provides a mechanism for session control 
and monitoring of the RTP data. RTCP is based on the periodic transmission of control 
packets (limited to a small and known fraction of the session bandwidth, at most 5%) to 
all participants in the session, using the same distribution mechanism as the data packets. 
As a compliment to RTP, it performs four main functions and these are: 

• Feedback Information. RTCP packets contain information such as the 
number of RTP packets sent, the number of packets lost, etc., which the 
receiving application or any other third party program can use to monitor 
network problems. The application might then change the transmission 
rate of the RTP packets to help reduce any problems. 

• Participant identification, used to keep track of each of the participants in 
a session. 

• Transmission Interval Control, which ensures that the control traffic will 
not overwhelm network resomces. 

• Minimal Session Control Information, an optional function which can be 
used to convey a minimal amount of information to all session 
participants, e.g. to exchange and display personal names of users joining 

or leaving an informal session. 
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It must be clarified that RTP and RTCP do not guarantee real-time 
delivery or prevent out-of-order delivery. They do not control quality of service in any 
way. This always requires the support of lower layers that actually have control over 
resources in internetworking devices. The network can drop, delay or desequence an RTP 
packet like any other IP packet. RTP and RTCP simply allow receivers to recover from 
network jitter by appropriate buffering and sequencing and to provide more information 
on the network so that appropriate corrective measures can be adopted. 

3. Video Considerations 

Packetized video traffic can be generated by interactive videoconference 
applications, which require low delay and jitter, and streaming video or video-on-demand 
that do not present tight timing constraints. A typical video application relies on TCP 
control channel and two UDP data channels, one for voice and one for video images. 


The transmission of images, moving or still, is one of the largest consuming 
applications. Simple digitization of a video signal can yield from 10Mbps for traditional 
full-motion television video to up to 1 Gbps for High Definition Television (HDTV). The 
size of each image, which is called frame, depends on the resolution of the picture. For 
example, an image with resolution of 352 by 240 pixels, with each pixel represented by 
24 bits of information, as would be the case for 24-bit color, results in a frame size of 
247.5 Kbytes. To provide TV video quality, the images must be provided in a frame rate 
of 25-30 frames per second that results in a bandwidth requirement of 59.4 Mbps [Ref 
9]. 


Thankfully, differentially compression algorithms and supporting hardware 
reduce the bandwidth requirements by about 100-fold or better. The compression consists 
of key frames that describe the entire image and intermediate frames that describe 
changes from the original frame. The high degree of video compression is achieved by 
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losing data (lossy compression) and by requiring a big amount of time to do the 
compression. Better image quality requires more information. 


H.261 is a video codec used in H.320 video conferencing to encode the image 
over several 64 Kbps ISDN connections. It is intended for compressed rates between 40 
Kbit/s and 2 Mbps. H263, another ITU compression standard, was designed for low bit 
rate, as low as 20 Kbps. Streaming video applications use MPEG-1 and MPEG-2 
compression standards that produce variable data rates in the range of 1.5 Mbps and 
6Mbps respectively. The recent years, development of low-bit-rate streaming media 
proprietary codecs (Real Player, Windows Media Player and Apple's QuickTime) has led 
to data rates that vary from 28Kbps to 768 Kbps, depending on the desired video quality. 
It is expected that MPEG-4 will manage to standardize and integrate them in an 
interoperable format. 

4. Synopsis Of Application Requirements 

While it's widely understood that inelastic applications are more critical because 
of human perception and sensitivity to network delay, elastic applications also require a 
certain level of service from the network to operate effectively. With the introduction of 
very demanding voice and video applications, it is no surprise that data-oriented 
applications are also beginning to cry out for proper service. Timely delivery is also 
necessary for even the classical bulk-data applications. Delays may be fatal to critical file 
or image transfers. A user downloading a web page would likely find excessively slow 
loads unacceptable, significantly limiting the usability of applications. 


Figure 9 provides a synopsis of the specific requirements of existing and 


emerging applications inside an organization. 


APPLICATION 

BANDWIDTH 

LATENCY 

JITTER 

PACKET 

LOSS 

File Transfer-Email- 
Web browsing 

Low-Medium 

> Is 

Allowed 

0% 
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Shared-Interactive Data 
Applications 


Low-Medium 


400 ms 


Allowed 


0 % 


Interactive Voice Conversation 

Low 

5.3-64Kbps 

150-200 ms 

30 ms 

<5% 

Interactive Videoconferencing 
Streaming Media 

Medium 

28-768Kbps 

400 ms 

30 ms 

<10% 

Video on demand/TV 

High 

1.5-6Mbps 

> Is 

Allowed 

<10% 

Imaging 

High 

8-100Mbps 

>ls 

Allowed 

0% 

Virtual Reality- 
Tele-immersion 

Very High 
>100 Mbps 

> Is 

Allowed 

0% 


Figure 9. Application Requirements In Terms of Performance Metrics. 
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III. QUALITY OF SERVICE PRINCIPLES AND FUNCTIONS 


A. QUALITY OF SERVICE DEFINITION 

Quality of Service (QoS) refers to the ability of a network to provide reliable and 
predictable service to selected network traffic. It refers to the ability of a network user or 
application to have some level of assurance that its traffic requirements can be satisfied. 


While QoS can be quantified using several criteria that incorporate performance, 
availability, reliability, and security, in the context of this thesis, QoS is defined as a 
measure of the service provided by the network, which is a composite of the previously 
analyzed four measmable components: 

• Data rate. 

• Delay. 

• Jitter. 

• Packet loss. 


As it was shown in the previous chapter, different applications have varying needs 
for QoS. Thus, to determine if a network offers proper QoS with respect of a specific 
connection, it is sufficient to determine if the performance traits are satisfied. 
Alternatively, we may also define intermediate levels of QoS that categorize it as 
excellent, good, fair, poor, or non-existent. For example, for a voice conversation, an end- 
to-end delay of less than 200 ms, with data rate of 64 Kbps, zero jitter, and packet loss of 
less than 5% could be considered excellent QoS, while a delay of 300 ms (others 
parameters the same) might be considered fair QoS. A delay of 500 ms or more would 
fall into the poor or nonexistent category. Similarly, for data applications, a file transfer 
with zero packet loss, 1 Mbps data rate and a reasonable timing delay would be 
considered excellent QoS. 
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QoS embraces a number of functions (prioritization, signaling, congestion control, 
policing) that intelligently match the needs of users and applications to the network 
resources available. These functions allow the treatment of certain packets in a 
preferential way, but also ensure that the less privileged flows do not starve and do get 
their fair service. Essentially, the goal of QoS is to enhance the current IP “best-effort” 
service, alleviate the inefficiencies and provide some level of performance guarantees. 


B. QUALITY OF SERVICE PRINCIPLES OF IMPLEMENTATION 

Applying a robust and scalable network-wide QoS solution in IP-based networks 
requires the cooperation of all network layers and a degree of coordination between end 
nodes and internetworking devices that does not exist today. That cooperation can be 
achieved by proper network engineering, based on the following principles: 

• Minimal change to the IP simplistic nature. It is necessary to preserve the 
connectionless and stateless orientation of IP, avoiding major overhauls 
and fundamental changes. 

• Weakest link principle. End-to-end QoS is determined by the weakest 
node encoxmtered by a particular flow in the path between sender and 
receiver. 

• Adding the necessary intelligence in each place and applying it as close as 
possible to the source of the problem. This usually implies the end 
systems, the applications and the border networking devices. For example, 
it makes sense to enable QoS in an application that will be afforded some 
kind of preferential treatment, but not in every application that is satisfied 
by the best-effort service model. 

• QoS should be as non-disruptive and transparent as possible to existing 
network operations and integrated in a single device that could be 
remotely manageable. 
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The overall objective is to meet all of these principles in a practical, affordable 
and cost-effective fashion, minimizing complexity of the network and involvement of 
network operators and end users. 


The successful implementation of QoS in the network will bring: 

• Control and efficient use of resources. Without creating additional 
network resources, existing ones can be allocated and managed more 
effectively, especially when the network is under heavy load and there are 
not enough resources to meet every demand. For instance, the network 
administrator can limit bandwidth consumed by data transfers over a 
backbone link and give priority to an important voice conversation. 

• Tailored services. QoS offers carefully tailored grades of service 
differentiation to the members of the organization. 

• Harmonic coexistence of elastic and inelastic applications. 

C. QUALITY OF SERVICE VS OVERPROVISIONING 

Until now, the need for service quality has been addressed by simply augmenting 
the capacity of the network (overprovisioning). There is still a big argument in favor of 
overprovisioning. Odlyzko [Ref. 10] argues that overprovisioning data networks is a 
viable and sustainable response to the demands for service quality. It supports that 
increasing the available bandwidth is technically and economically superior to 
implementing complicated QoS techniques that add overhead to the network. 


The objections against the implementation of a QoS scheme are based on the fact 
that eventually the entire system will become more complicated, increasing the 
computational burden on the networking devices and increasing the numbers and lengths 
of queues. On the contrary, as bandwidth becomes cheaper and more available with 
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technologies such as Gigabit Ethernet and high-speed optical WAN circuits, networks 
will operate so fast that will be able to satisfy the needs of all applications. 


The capacity increase is a necessary step, but not sufficient to overcome all 
hindrances for the following reasons: 

• It is a fundamental law of economics that demand will always expand 
beyond the supply of resources to cause congestion and queues. There will 
always be new bandwidth-hungry applications that will overrun the 
network capacity limits, especially during high-demand periods, no matter 
how much bandwidth the network can provide. 

• Despite the fact that bandwidth becomes a commodity, it will take a long 
time and capital to provide sufficient bandwidth everywhere. 

• Increasing bandwidth only is not enough to satisfy low delay and jitter. 
Voice traffic does not require much bandwidth (a conversation can be 
compressed to 8 kbps), but it has very strict requirements with respect to 
delay and jitter. 

• Wireless networking, which is expanding rapidly, presents restricted 
bandwidths and will always be lagging in terms of bandwidth in 
comparison with terrestrial links and wired campus networks. Especially 
for a military organization, microwave RF and satellite systems, which 
mainly serve the communication channels, present important bandwidth 
mismatches, as depicted in Figure 10. 
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Figure 10. Bandwidth Mismatches In Military Network. “From Ref. 11” 


Therefore, it is acceptable to throw bandwidth at the network, when it is cost 
effective to do so. However, without meaningful control mechanisms, even a network of 
enormous bandwidth cannot guarantee sufficient performance and is likely to saturate. 
QoS remains an essential technology, no matter how complicated, to deal effectively with 
an environment of finite resources, link capacity mismatches and diverse traffic patterns. 
The real challenge is to keep an optimum balance between the two approaches and have 
them complement each other, so that a network can give each application the resources it 
needs. 

D. QUALITY OF SERVICE FUNCTIONS 

QoS provides better and more predictable network service by accomplishing the 
following functions: 

• Prioritizing traffic 

• Signaling traffic requirements 
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• Congestion control 

• Policing (admission control) 

1. Prioritizing Traffic 

One of the basic building functions of QoS is the ability to partition network 
traffic into different service classes or priority levels. To accomplish this, the packets 
must carry an explicit classification field and network devices must be able to identify it 
throughout the network and treat it accordingly. The classification process may be based 
on the following options [Ref 12]: 

• User desire: Giving packets preferential treatment whenever the user 

decides he would like preferred service. Obviously, there could be an 
abuse problem with this strategy, if it is not accompanied by 
complementary traffic shaping and admission control mechanisms. 

• User privilege: Giving packets preferential treatment if they are associated 
with an entity that has been designated as eligible for priority treatment. 
The reason a particular user's end-system might be entitled to such 
privilege could be related to the user's rank, or affiliation with a special 
project, or by virtue of having subscribed to a preferred network service 
level. 

• Application need: Giving packets preferential treatment, if they are sent by 
an application, whose need for certain network characteristics are 
network-wide known. It should be noted that application need is a relative 
and not an absolute concept. The actual need for any particular application 
may differ with circumstances. For example, high quality for a desktop 
videoconference may be more important in a commanders’ brief than in 
the case of a sailor communicating with his family. 
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The network must be able to mark and prioritize certain fields of the packets 
entering the system and the networking devices will then use these fields in deciding how 
to treat these packets. The following two ways have been widely used so far: 


a. Type of Service (TOS) Byte in IP Header 

Originally, the IPv4 header included a b)4e, named Type of Service 
(TOS), which provided a way for differentiation and classification, but it had remained 
unimplemented and xmused. The need for prioritizing resulted in TOS byte activation. 
Initially, the first three bits were determined to indicate relative priority of the packet, 
known as IP precedence, and the values these bits can take are described in RFC 791. As 
shown in figure 11, these three bits allow partitioning of traffic in up to 8 priority levels. 


IPv4 TOS BYTE 


0 1 2 3 4 5 6 7 


IP PRECEDENCE 


TYPE OF SERVICE 


MBZ 


111 - Network Control 

110 - Internetwork 
C ontrol 

101 - CRITIC/ECP 
100 - Flash Override 
on - Flash 
010 -1mmediate 
001 - Priority 
000 - Routine 


1000 — minimize delay 
0100 — maximize throughput 
0010 — maximize reliability 
0001 — minimize monetary cost 
0000 — normal service 


Figure 11. IPv4 Type Of Service (TOS) Byte. 


The next four bits of the TOS byte represent 4 metrics (delay, throughput, 
reliability and monetary-cost), as defined in RFC 1349, that denote how the network 
should make tradeoffs between throughput, delay, reliability, and cost. The final bit is 
unused and must be set to zero. 
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The Differentiated Services model (examined in the following chapter) renames 
the TOS byte to DiffServ field and defines new priorities based on the first six bits of the 
DiffServ field, while the remaining two are unused. The latest version of operating 
systems let applications and networking devices to manipulate this byte, allowing the 
flexibility to define up to 64 different priority levels. 

b. 802.1p Bits in MAC Header 

Most local area networks (LAN) are based on IEEE 802 technology. 
These include Ethernet, Token-ring, FDDI and other variations of shared media 
networks. 802. Ip defines three bits in the MAC header of 802 packets that can cany one 
of eight priority values, corresponding to one of eight possible service levels in the LAN 
network. Typically, hosts or routers sending traffic into a LAN can mark the MAC 
header bits of each transmitted packet with the appropriate priority value. LAN devices, 
such as switches, bridges and hubs, are expected to treat the packets accordingly. It is 
important to mention that the value of this prioritization technique is limited because the 
scope of the 802. Ip priority mark is limited to the LAN environment. Once packets are 
earned off the LAN, through a layer-3 device, the 802. Ip priority is removed or has to be 
mapped in a higher layer priority scheme. 

2. Signaling Traffic Requirements 

Another way to request certain service from the network is to signal traffic 
requirements before data transmission. The Resource Reservation Protocol (RSVP), 
described in RFC 2205, was developed to be the standard mechanism to precisely signal 
QoS requirements to the network infrastmeture. It should be noted that RSVP does not 
provide additional resources; it only reserves a portion of the existing ones. RSVP allows 
an application (or a network device on behalf of an application) to dynamically reserve 
network resources. The application signals its service requirements to all devices in the 
network that will handle the associated traffic, ensuring transfer of traffic in a 
deterministic and consistent manner. 
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RSVP is not a routing protocol, nor is it part of the routing architecture of the 
network devices involved in packet forwarding. It does not perform its own routing, but 
instead it uses underlying routing protocols to determine where it should carry reservation 
requests. RSVP messages are transmitted directly on top of the IP protocol as opposed to 
being transmitted over TCP or UDP. 


RSVP requests the QoS on behalf of a particular flow. The protocol follows the 
receiver-based model. Figure 12 illustrates how RSVP works. Each RSVP sender sends a 
description of the characteristics of the traffic flow it intends to generate and reserve, 
usually in terms of bandwidth and latency. These resource requests are encoded in 
parameters within the RSVP “PATH” message and are transmitted from the sender to the 
receiver along the data path, provided by the routing protocol. At each node, RSVP 
attempts to make a resource reservation for the flow, determining whether the node has 
sufficient available resources to supply the requested QoS. In case of finding available 
local resources to support QoS requests, the “PATH” messages store path state in each 
node along the way. This path state includes at least the IP address of the previous hop 
node, which is used to route the “RES V” messages hop by hop in the reverse direction. 
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Figure 12. RSVP Signaling Process. 

The receiver, as well as every RSVP-capable device along the path, is aware of 
the sender’s traffic. The receiver of the data flow determines what QoS the flow will 
actually receive, sending the RSVP “RESV” message upstream along the same path 
toward the sender. This determination may be dependent on the receiver’s capabilities, 
the application requirements or other administrative considerations. The “RESV” 
messages create and maintain reservation state in each node along the path. “RESV” 
messages are finally delivered to the sender, so that the host can set up appropriate traffic 
control parameters for the first hop. 


Thus, for RSVP, characterization of the flow is the sender’s responsibility, while 
the receiver specifies its particular service requirements. “PATH” messages are sent with 
the same source and destination addresses as the data, so that they will be routed correctly 
through non-RSVP clouds. On the other hand, “RESV” messages are sent hop by hop. 
Each RSVP-aware node forwards a “RESV” message to the address of a previous RSVP 
hop. 
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RSVP messages install state on devices along a data path. But to manage states 
across a network, the soft state model is used. RSVP sends periodic refresh messages to 
maintain the state along the reserved paths. In the absence of a timely refresh message, 
the state automatically times out and is deleted. As routing changes paths to adapt to 
topology changes, RSVP adapts its reservation to the new paths wherever reservations 
are in place. This technique is powerful in that it solves the problems associated with 
deallocation of reservations, lost packets and route changes (RFC 2210). 

3. Congestion Control 

a. Managing Congestion With Queuing Techniques 

Congestion management is used to control congestion after it occurs. 
Network devices handle an overflow in arriving traffic by using smart queuing techniques 
that efficiently prioritize and handle traffic in a more effective manner than the traditional 
first-in-first-out (FIFO) technique [Ref 13]. These techniques are: 

• Priority queuing 

• Custom queuing 

• Weighted Fair Queuing 


Priority queuing is a basic scheme that gives designated higher priority 
traffic absolute preferential treatment over low-priority traffic. It ensures that important 
traffic is queued ahead of other traffic and gets the fastest available handling. It provides 
no means of controlling the allocation of bandwidth, and often results in all but the 
highest priority applications being starved of bandwidth. 


Custom queuing handles traffic by assigning different amounts of queue 

space to the various classes of traffic and then servicing the queues in a round-robin 

fashion. While a particular traffic can be assigned more queue space, it can never 
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monopolize all the bandwidth. All different streams of data are guaranteed a minimum 
quantity of bandwidth. This feature serves well traffic with specific minimum bandwidth 
or delay requirements, while still permitting other network applications to run effectively. 


Weighted Fair Queuing (WFQ), the most sophisticated queuing technique, 
differentiates among bandwidth-hogging applications and those that need less bandwidth, 
and distributes the bandwidth to all applications in equal amounts. It is a flow-based 
queuing algorithm that does two things simultaneously. It schedules interactive traffic to 
the front of the queue to reduce response time, and it fairly shares the remaining 
bandwidth among high-bandwidth flows. WFQ ensures that queues do not starve for 
bandwidth, and that traffic gets predictable service. Low-volume traffic streams, which 
comprise the majority of traffic, receive preferential service, transmitting their entire 
offered loads in a timely fashion. High-volume traffic streams share the remaining 
capacity proportionally between them. WFQ is efficient in that it uses whatever 
bandwidth is available to forward traffic from lower-priority flows if no traffic from 
higher-priority flows is present. 

b. Avoiding Congestion by Proactively Dropping Packets 

There are certain congestion avoidance techniques that monitor network 
traffic loads in an effort to anticipate and avoid congestion at common network 
bottlenecks through packet dropping. Random early detection (RED) has emerged as the 
standard congestion avoidance method. In basic form, RED randomly drops packets as 
queues fill up, causing end stations to decrease their transmission rates so queues will not 
overflow. If the forwarding device is not configured with RED, it uses the cruder default 
packet drop mechanism called “tail drop”. Tail drop treats all traffic equally and does not 
differentiate between classes of service. Queues fill during periods of congestion. When 
the output queue is full and tail drop is in effect, packets are dropped until the congestion 
is eliminated and the queue is no longer full. 
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The RED mechanism was proposed by Sally Floyd and Van Jacobson in 
the early 1990s to address network congestion in a proactive rather than reactive manner. 
Underlying the RED mechanism is the premise that most traffic runs on top of TCP, 
which is sensitive to loss and will temporarily slow down when some of their traffic is 
dropped. The main goal of RED is to improve the efficiency of TCP congestion control. 
TCP, which responds appropriately to traffic drop by slowing down its traffic 
transmission, effectively allows RED traffic-drop behavior to work as a congestion- 
avoidance signaling mechanism. Given the ubiquitous presence of TCP, RED offers a 
widespread, effective congestion-avoidance mechanism. 


Weighted Random Early Detection (WRED) combines the capabilities of 
the RED algorithm with IP Precedence to provide for preferential traffic handling of 
higher priority packets. WRED can selectively discard lower priority traffic when the 
interface begins to get congested and provide differentiated performance characteristics 
for different classes of service. WRED can also work with interfaces configured to use 
RSVP, where WRED chooses packets firom other flows to drop rather than the RSVP 
flows. 


c. Traffic Shaping /Rate Limiting 

It is often the case that a particular link has sufficient capacity for the 
offered load if the load is more evenly spaced in time. In reasonably provisioned 
networks, congestion usually results from the peaks. When demand peaks at certain 
times, the link is not capable of handling the instantaneous demand. Traffic shaping 
means modifying the timing of a sequence of packets so as to reduce burstiness. It does 
not reduce total network demand, but it smoothes out the peak demands, shifting demand 
firom peak times to off-peak times. 


The primary reasons traffic shaping is used are to control access to 
available bandwidth, to ensure that traffic conforms to the policies established for it, and 
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to regulate the flow of traffic in order to avoid congestion that can occur when the 
transmitted traffic exceeds the access speed of its remote interface. Hence, traffic shaping 
can be a very important part for congestion avoidance, eliminating bottlenecks especially 
in topologies with data-rate mismatches. For example, if one end of the link in a Frame 
Relay network runs at 256 kbps and the other end of the link runs at 128 kbps, sending 
packets at 256 kbps could cause link congestion. 


Rate limiting provides the means to allocate bandwidth commitments and 
limitations to traffic sources and destinations, while specifying the actions for handling 
traffic that exceeds these allocations. Essentially, it dictates a maximum amount of 
bandwidth that a particular application can consume. For example, the first 100 Kbps of 
video traffic generated by a video streaming application can be allowed to go through in a 
preferential manner, but traffic above the first 100 Kbps by the same application can drop 
to lower priority or be discarded. Similarly, file transfer traffic can be limited to 20% of 
all available bandwidth so that it does not starve out other applications. 

d. Packet Size Optimization and Fragmentation 

Time-sensitive traffic is susceptible to increased delay and jitter when the 
network processes large packets, especially when the packets are queued on slower links. 
In a slow link, a large packet can make the connection unavailable to other packets for a 
considerable amount of time. As shown in figure 13, a large frame of 1500 bytes (typical 
Ethernet packet) takes 215 ms to traverse a 56-kbps line, which exceeds the overall delay 
requirement for time-sensitive traffic (150-200 ms). Therefore, to limit the delay of time- 
sensitive packets on relatively slow bandwidth links, a method for fragmenting larger 
packets and queuing smaller packets between fragments of the large packet is needed. 
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Figure 13. Packet Size Optimization And Fragmentation. 


Packet size optimization and fragmentation provides a method of splitting, 
recombining, and sequencing packets that reduces transmission delay across slow 
bandwidth WAN links. Large datagrams are multilink encapsulated and fragmented to 
packets of a size small enough to satisfy the delay requirements of the delay-sensitive 
traffic, while small delay-sensitive packets are interleaved with the smaller packets 
resulting from the fragmented datagram. 


e. Protocol Header Compression 

The header portion of IP/UDP/RTP is considerably large. As shown in 
figure 15, the minimal 12 bytes of the RTP header, combined with 20 bytes of BP header 
and 8 bytes of UDP header, create a 40-byte IP/UDP/RTP header. For audio applications, 
the packet payload typically varies from 20 bytes to 160 bytes, depending on the CODEC 
used. Given the size of the P/UDP/RTP header combination, it is inefficient to transmit 
the BP/UDP/RTP header without compressing it. To avoid the uimecessary consumption 
of available bandwidth, the protocol header compression feature is used on a link-by-link 
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basis. It compresses the IP/UDP/RTP packet header from 40 bytes to approximately 2 to 
5 bytes, as shown in figure 14. 


40 BYTES 20-160 BYTES 


2 0 __ 8 . , 12 



Figure 14. Protocol Header Compression. 


This feature accrues major gain in terms of packet compression, because 
although several fields in the header change in every packet, the difference from packet 
to packet is often constant, and therefore the second-order difference is zero. The 
decompressor can reconstruct the original header without any loss of information. 


The overhead reduction for multimedia RTP traffic results in a 
corresponding reduction in delay. The header compression is especially beneficial when 
the payload size is small, for example, for compressed audio payloads of 20 to 50 bytes. 
It is recommended on any WAN interface, where bandwidth is a concern and there is a 
high portion of RTP traffic. It should not be used on any high-speed interfaces, anything 
over T1 speed, because the trade-offs are not desirable. 

4. Policing 

Since enabling QoS on an IP network effectively means that some users will get 
better network service than others, it creates some incentive to steal or abuse the 
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resources. Therefore, there is a need for a policing and admission control scheme to 
authenticate those that request the better service levels and to verify the identity of traffic 
“owners” on a per-packet basis. In the absence of a policing scheme, traffic owners 
would mark their packets as desirous of preferential treatment, all packets will in fact 
would become high-priority packets, and the outcome would be another “best-effort” 
network. 


Since there are varying circumstances in which traffic owners (end-users, 
applications, host machines) are entitled to the services they request, there is a need for a 
set of rules, a need to decide when these rules apply and a need to enforce them. The 
rules, the judging and enforcing devices, all comprise a policy system that is an essential 
component of a QoS-enabled network [Ref. 14]. 


Policy is one or more rules that describe the actions to occur when specific 
conditions exist. Policies determine which applications and users are entitled to varying 
amoimts of resources in different parts of the network. Policy rules, conditions and 
actions, must be unambiguous and verifiable. There should be only one correct rule 
appropriate for any specific set of conditions so that network personnel can configure 
QoS mechanisms subject to these rules. Several parameters can be selected to reflect a 
defined policy, such as IP or MAC address, application port, user, time of day, or location 
within the network. 


Even network management teams, who have well-planned QoS policies, find that 
implementing and enforcing them throughout a large network is a complicated and 
sometimes overwhelming task. Even with advanced, intelligent network devices and the 
latest management tools, the fact remains that in today’s networks, the configuration is 
often veiy complex. It is often done by hand, through a command-line interface (CLI), 
one device at a time. Few network administrators have the time or experience to correctly 
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implement end-to-end QoS policy in every device. This shortfall often results in 
inconsistent policy implementation and a lack of d3mamic application control. 


Clearly, there is a need for a simpler, higher-level way to implement policy 
without requiring a detailed understanding of the mechanisms and the lower-level 
configuration and maintenance management. The Resource Allocation Protocol (RAP) 
Working Group in the IETF was originally assigned to '^establish a scalable policy 
control model”. The Policy Framework they designed [Ref. 15] was quickly accepted by 
the networking industry and recognized as being applicable to the whole network. Indeed, 
it has since been recognized as a generally useful model for other technologies that need 

policy support, such as network security (for firewalls, P Security, Virtual Private 
Networks). 


The framework is relatively simple, as shown in figure 15, and comprised by the 
following policy architectural components: 

• Policy decision point (PDP), which translates network-wide higher layer 
policies into specific configuration information for individual network 
devices. PDP also inspects resource requests carried in RSVP messages 
and accepts or rejects them based on a comparison against policy d at a 

• Policy enforcement point (PEP), which acts on the decisions made by 
PDP. This is typically a network device that either does or does not grant 
resources to arriving traffic. 

• A policy data repository, typically stored in a directory, which contains the 
policy data, represented as data structures so they can be stored and 
retrieved, such as user names, applications, and the network resources to 
which these are entitled. 

• Protocols that enable communication between the data repository, PDP 
and PEP. 
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Figure 15. Policy Framework. 


In a sense, PDP is the judge that makes decisions based on the policies it retrieves 
from the policy data repository and PEP is the enforcing device that applies the decisions 
of PDP. 


To make its decisions, the PDP consults the data repository for the rules 
established by the network manager and decides, based on current network conditions, 
how traffic and access rights should be enforced. A protocol is required for the 
communication between the PDP and the policy data repository. Since the data repository 
tends to take the form of a distributed directory. Lightweight Directory Access Protocol 
(LDAP) is commonly used for this purpose, so multiple network applications can share 
and make decisions based on the information. 


Once the PDP has made a decision on how to treat network traffic, it 
communicates the instructions to the PEPs (routers, switches, and gateways) via a 
protocol named Common Open Policy Service (COPS). It is a simple query/response 
protocol that has been developed in the context of QoS. It was initially targeted as an 
RSVP-related policy protocol but has recently been pressed into service as a general 
configuration protocol. COPS is preferred because it is connection-oriented and reliable. 
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and includes locking mechanisms to prevent multiple PDFs from simultaneously 
attempting to update the same PEP. 


The separation of PEP and PDP is a logical one, based on functionality and not 
necessarily a physical separation. In certain cases, the PEP and the PDP can be co-located 
in the same networking device. In other cases, the PDP may be separated from the PEP in 
the form of a policy server. A single policy server may reside between the directory and 
multiple PEPs, as shown in figure 16. Although many policy decisions can be made 
trivially by co-locating the PDP and the PEP, scalability issues can be better addressed by 
the use of a separate policy server. Recently, work is proceeding on the concept of a 
bandwidth broker [Ref 16]. The bandwidth broker concept is similar to a PDP in the 
sense that it makes decisions regarding bandwidth provisioning. However, bandwidth 
brokers tend to operate at a higher level than PDFs, operating at the edges between 
domains and being less aware of the topologies within domains. 


Gradually, DNS, DHCP and authentication servers can be integrated that will 
dynamically update the directory with IP address-to-device and address-to-user 
association information. Ultimately, the objective is the network to dynamically learn of 
changes from the directoiy and to reconfigure itself to ensure that QoS policies are 
appropriately applied. 
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As issues of scalability, interoperability and ease of use are resolved, this 
framework can enable automatic implementation of defined policies in the network. This 
will substantially increase network integrity while reducing dramatically the required 
human resources to implement and maintain QoS. While it will require the integration of 
multiple servers, directories, protocols and network devices, the above policy framework 
is expected to be the only reasonable way to police a converged voice/data/video network 
in a dynamic and efficient way. 
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IV. QUALITY OF SERVICE MODELS 


In the previous chapter, several mechanisms and functions were examined that 
can contribute to the QoS implementation. To deliver end-to-end service guarantees and 
create reliable performance outcomes, these mechanisms must be applied in concert. 
Essentially, there are two basic approaches that provide QoS capabilities network-wide 
and IETF has developed two standards that reflect these approaches. Integrated Services 
(IntServ) provide QoS to individual applications or flows and Differentiated Services 
(DiffServ) provide QoS to aggregated traffic. The purpose of this chapter is to examine 
the principles of each QoS model, gain an understanding of their respective strengths and 
weaknesses and examine the recent development of a hybrid model that combines the 
strengths of both models. 


A. INTEGRATED SERVICES MODEL 

The Integrated Services (IntServ) model was the initial approach of IETF. This 
model relies on the creation of a reservation state within the network that corresponds to 
a service request and maintains this state for the duration of the associated flow. 


In this model, it is the application that requests through explicit signaling a 
specific QoS from the network before sending data. The application informs the network 
of its traffic profile and requests a particular kind of service that can encompass its 
bandwidth and delay requirements. The application is expected to send data that lies 
within its described traffic profile only after it gets a confirmation from the network. 


The network performs admission control, based on information from the 
application and available network resources. It also commits to meeting the QoS 
requirements of the application as long as the traffic remains within the profile 
specifications. The network fulfills its commitment by maintaining per-flow state and 
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then performing packet classification, policing, and intelligent queuing based on that 
state. 


RSVP (examined in chapter HI) fulfills the role of explicit signaling. This end-to- 
end signaling protocol provides a way to communicate the application's requirements to 
network elements along the path between sender and receiver, and to convey QoS 
management information network-wide. This imposes flow-specific state in the network 
elements, which represents an important and fundamental change to the simple IP model. 


IntServ defines three levels of service: 

• Guaranteed service (RFC 2212), with bandwidth, maximum bounded 
delay, and no-loss guarantees. Service is guaranteed to be within these 
limits and that allows applications to meet their requirements. For 
example, a Voice over IP (VoIP) application can reserve 32 Kbps data rate 
end-to-end along the path. 

• Controlled load service (RFC 2211), which approximates best-effort 
service in a lightly loaded network and allows applications to have low 
delay and high throughput even during times of congestion. For example, 
streaming media applications can use this kind of service. 

• Best-effort service, similar to what the IP network currently provides 
under a variety of load conditions. 

1. IntServ Strengths 

An important strength of the IntServ model is guaranteed delay bounds for an 
individual flow. If all nodes are RSVP-aware, then there will be an absolute upper bound 
on the network delay of the traffic. This can apply not just to one hop, but network-wide. 
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Furthermore, the IntServ model avoids service degradation. RSVP provides the 
ability to reject connections that if admitted would receive unacceptable QoS and also 
degrade the QoS of other reservations in progress. This capability derives from the 
messages RSVP sends along the path that packets will travel if the cormection is 
established. 


RSVP is designed to operate with current and future unicast and multicast routing 
protocols. Since the membership of a large multicast group and the resulting multicast 
tree topology are likely to change with time, RSVP sends periodic refresh messages to 
maintain the state along the reserved path. In the absence of refresh messages, the state 
automatically times out and is deleted. 


Controlled link sharing is another benefit of the IntServ model. It is feasible not to 
put bounds on delay, but to limit overload shares (oversubscription) on a link, while 
allowing any mix of traffic to proceed if there is spare capacity. 

2. IntServ Weaknesses 

The most problematic issue is that IntServ maintains individual flow states to the 
network links for all accepted reservations that have been made. This represents a 
fundamental change to the stateless and connectionless IP architecture that was founded 
on the concept that all flow-related state should remain in the end systems. 

Lack of scalability is another IntServ weakness, especially in high-speed 
backbone networks. Indeed, the amount of resources that a router needs for RSVP 
processing and storage increases proportionally with the number of IntServ flows. Traffic 
measurements show [Ref. 17] that most end-to-end IP connections are very short-lived, 
and that there are several thousand active connections at any time in a backbone router. 
Consequently, numerous IntServ flows on a high-bandwidth link place an excessive 
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burden on routers. Furthermore, if a topology change occurs, the reservations would need 
to be renegotiated simultaneously. 

B. DIFFERENTIATED SERVICES MODEL 

Differentiated services (DiffServ), described in RFC 2474, is a service model that 
was designed to satisfy differing QoS requirements, operating on layer 3 (IP) of the 
TCP/IP protocol stack, preserving the stateless and connectionless nature of the ff 
network. To overcome the limitations of the IntServ model, DiffServ merges individual 
flows into fewer and finite aggregates. In contrast to IntServ orientation, there is no need 
for per-flow state and explicit signaling at every hop inside a DiffServ network. 


For differentiated service, the network tries to deliver a particular kind of service 
based on classification of each packet. This classification takes place in the DiffServ 
field, which supersedes the existing definitions of the IPv4 Type of Service (ToS) byte 
(RFC 1349) and the IPv6 Traffic Class byte (RFC 2460). As shown in Figure 17, six bits 
of the DiffServ field (formerly TOS byte) are used as the DiffServ Code Point (DSCP), 
while the rest two remain unused. Each DSCP is a six-bit value that identifies a particular 
Per-Hop Behavior (PHB) that a network element applies to each packet. DiffServ has 
subsumed IP precedence, but maintains backward compatibility. 

^ -]_2_3_4_ 5 6 7 
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Figure 17. DiffServ Field. 

PHBs are at the heart of the DiffServ architecture. A PHB is selected at each node 
by mapping the DSCP in each received packet. The PHB is the means by which a node 
allocates resources to behavior aggregates. PHBs are implemented in nodes by means of 
some buffer management and packet scheduling mechanisms. The IETF has recently 
specified two PHBs for standardization: 
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• Expedited Forwarding (EF), specified in RFC 2598. Packets marked with 
EF (DSCP 101110 is recommended) are forwarded with minimal delay, 
low jitter, low loss and assured bandwidth at each hop through DiffServ 
domains. 

• Assured Forwarding (AF), specified in RFC 2597. The AF PHB group 
provides IP packet delivery in four independently forwarded AF classes. 
Within each AF class, an IP packet can be assigned a certain amount of 
forwarding resources (buffer space and bandwidth) and one of three levels 
of drop precedence. In case of congestion, the drop precedence of a packet 
determines the relative importance of the packet within the AF class. 


The DifIServ model achieves scalability by aggregating the traffic classification 
state, which is conveyed by the marking of the DiffServ field of each IP packet. Packets 
are classified and marked to receive a particular PHB on nodes along their paths. 
Sophisticated classification, marking, policing, and shaping operations need only be 
implemented at network boundaries or hosts. Network resources are allocated to traffic 
streams by service-provisioning policies that govern how traffic is marked and 
conditioned upon entry to a DiffServ-capable network, as well as how that traffic is 
forwarded within that network. A wide variety of link characteristics-bandwidth, delay, 
jitter, and/or loss-can be controlled and adjusted accordingly. 


Packet markers set the DiffServ field of a packet to a particular DSCP, adding the 
marked packet to a particular DiffServ behavior aggregate. Shapers delay some or all of 
the packets in a traffic stream to bring the stream into compliance with a traffic profile. A 
shaper usually has a finite-size buffer, and packets may be discarded if there is 
insufficient buffer space to hold the delayed packets. Droppers discard some or all of the 
packets in a traffic stream to bring the stream into compliance with a traffic profile. 
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1 . 


DiffServ Strengths 


Unlike RSVP, no QoS requirements are exchanged between the source and the 
destination, eliminating the inherent setup costs associated with RSVP. Short-lived flows 
benefit from DiffServ because the absence of QoS setup costs improves responsiveness 
and reduces the overhead required for a quick discussion with another host. 


In case of congestion, flows will adapt their traffic to the available resources and 
continue operating, albeit at lower levels of service. The benefit is higher overall 
efficiency-more flows get through with greater simplicity, minimal signaling support, and 
simple data-path mechanisms 


2. DiffServ Weaknesses 

DiffServ only maps services with different levels of “sensitivities” to delay and 
loss, without being associated with explicit values or guarantees. It does not attempt to 
guarantee a level of service. Instead, it strives for a relative ordering of aggregations, 
such that one traffic aggregation will receive better or worse treatment relative to other 
aggregations, based on the behavioral rules of each aggregation. 

C. AN INTEGRATED/DIFFERENTIATED HYBRID MODEL 

Together, IntServ and DiffServ can facilitate QoS deployment of applications. A 
hybrid framework, as shown in figure 18 has been proposed [Ref 18] and seems to have 
strong support and momentum. It assumes a model in which peripheral networks are 
IntServ-aware and interconnected by DiffServ networks. 
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Figure 18. An IntegratedyDifferentiated Hybrid Model. 


In this model, the scalability of DiffServ networks extends the reach of 
IntServ/RSVP networks. Intervening DiffServ networks appear as a single RSVP hop to 
the IntServ/RSVP networks. Hosts attached to the peripheral IntServ/RSVP networks 
signal to each other for per-flow resource requests across the DiffServ networks. 
Standard IntServ/RSVP processing is applied within the IntServ/RSVP peripheral 
networks. RSVP signaling messages are carried transparently through the DiffServ 
networks. Devices at the boundaries between the IntServ/RSVP networks and the 
DiffServ networks process the RSVP messages and provide admission control based on 
the resource availability within the DiffServ network. 


Adequate IntServ and DiffServ mapping at the boundaries and suitable resource 
provisioning in the core are essential to ensure that the performance across the transit 
network does not defeat the end-to-end QoS. IntServ is implemented at the edge of 
organization LAN networks, where user flows can be managed at the desktop level. 
DiffServ plays a key role in the core WAN network where it eliminates the scalability 
concerns of IntServ/RSVP networks. With this model, it is possible maintain the 
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fundamental principle of IP network that leaves complexity at the ‘edges’ and keeps the 
network ‘core’ simple. 


An important driver for IntServ in the vicinity of the end hosts is the 
implementation of RSVP and QoS capabilities in modem desktop operating systems. The 
use of RSVP signaling provides admission control to the DiffServ network, based on 
resource availability and policy decisions. It also greatly simplifies the configuration of 
DiffServ classifiers, policies, and other traffic conditioning components. 
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V. FUTURE NETWORK INFRASTRUCTURE PROPOSITION 


The network infrastructure must be able to support today’s needs while preparing 
for tomorrow’s technological changes. This chapter discusses the alternatives and then 
points to the preferred direction to move forward. Essentially, there are three options: 

1. Maintain voice and data networks separately. The voice network provides 
the quality of service that is desired only for voice. Data networks can sufficiently serve 
bandwidth intensive data applications. 

2. Move towards an IP-based integrated voice, video and data network by 
adding bandwidth to the network. Up to now, this was mainly the approach that had been 
followed by the industry to overcome the network bottlenecks. 

3. Move towards an IP-based integrated voice, video and data network with 
the deployment of extensive QoS and traffic management mechanisms. 


The connection-oriented nature of the voice network and the support for relatively 
low bandwidth does not make it suitable for a network that can accommodate the 
increased need for high-speed digital access and the expansion of intensive data and 
video applications. As analyzed in Chapter H, the benefits of a converged network are 
enormous and therefore it is inevitable to integrate in a robust and dynamic IP-based 
network, because it has the potential to serve as the basis of a multiservice network. 
Therefore, following the first option of keepihg the two networks separately does not 
present a scalable, economic and robust solution. Nevertheless, the organizations have 
invested heavily in enterprise voice equipment that will take several years to depreciate. 
The result is that organizations view IP migration as a multiple year project requiring 
incremental steps and major outlays of resources. During this transition, voice networks 
will be around serving voice communications but eventually will fade away, replaced by 
voice over ff. 
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The second option, throwing capacity only in the IP infrastructure, is a necessary 
step, but not sufficient to overcome all network performance deficiencies of a 
multiservice network, as anal 5 ^ed in Chapter HI. It is desirable to increase the bandwidth 
of the network, but it is not wise to consider it as panacea, because it is not always 
economically and technically feasible. 


The third approach, implementing QoS only, compounds management complexity 
and creates additional overhead and latency in the network. Consequently, the entire 
network may become more complicated, increasing the computational burden on the 
networking devices. QoS is not enough if it is not supported by sufficient capacity. 


Therefore, the proposition of this thesis is that a combination of the second and 
third approach is the proper direction to be followed. The proposed approach is to keep 
an optimum balance between bandwidth increase and QoS deployment and have them 
complement each other, so that the IP-based network can deal effectively with diverse 
traffic patterns, user differentiation and link capacity mismatches. 


This approach can overcome all the major deficiencies of the IP-based network 
and raise it in a higher degree of maturity and reliability. Deploying QoS on the IP-based 
network should be approached systematically, with scalability and robustness in mind 
and in tandem, proper redesign and upgrade of the network will provide the necessary 
capacity. The migration and road to convergence will be a bumpy ride and will take time 
and careful planning. New techniques and applications must be deployed and thoroughly 
tested on a large scale to mitigate the risks associated with availability, fault tolerance, 
and redundancy The remainder of this chapter explains how to achieve the proposed 
approach. 
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A. UPGRADE OF NETWORK INFRASTRUCTURE THROUGH FIBER 
OPTICS DEPLOYMENT 

As it was mentioned, bandwidth increase was the first reaction of the industry to 
the IP network performance problems. The increased demand for capacity, quickly 
consumed all available bandwidth afforded by wire-based media such as twisted pair and 
coaxial cable. To alleviate this problem, the networking industry has turned to a new 
medium, fiber optic. 


Fiber has also undergone tremendous growth in the past decade. Communication 
companies have realized the advantages of fiber optics and have invested heavily into 
replacing wire-based circuits with this medium. Fiber has been deployed extensively in 
network backbones, especially at WANs, campus backbones and between floors and 
buildings, but fiber to the desktop or to the home still remains an expensive proposition. 
Copper is still much more prominent for the end hosts than fiber. 


Fiber presents several advantages over the other physical media. Certainly the 
biggest gain is its enormous bandwidth capability enabling it to handle tremendous digital 
data rates with near error-free transmission. Other distinct benefits include: 

• Reduced size and weight, 20 times lighter and 5 times smaller than 
equivalent copper cable. 

• Transmission over longer distances. 

• Permanence of the cable plant (network upgrades are limited to network 
electronics and software). 

• Added security due to its resistance to unauthorized tapping. 

• Superior quality attributes (fiber is free from signal cross-talk and 
electromagnetic interference). 
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Until recently, the cost of fiber technology made it unsuitable for all but the 
largest communications systems and networks. Advances in technology however, have 
changed this. Improvements in fiber optic quality, light sources, light detectors, and the 
procedures used to splice circuits have reduced the cost of implementing this medium. 
Fiber optics is now a feasible solution to the bandwidth limitation problems in residential 
areas and networks that support hundreds of nodes. 


Despite being up to 50% more expensive than copper category 5, the cost of 
installing fiber-to-the desktop is dropping rapidly and that will drive fiber further into the 
organization. Ironically, the physical fiber cable is the least expensive element. 
Electronics and density connectors constitute the most expensive elements. These are also 
responsible for the creation of the capacity limitations. In theory, fiber can be used to 
transmit between 50 and 75 terabits per second [Ref 19]. Currently deployed 
transmission technology supports 10 Gbps fiber channels. However, the deployment of 
Wave Division Multiplexing (WDM) is expected to lift the transmission rates to between 
100 Gbps and 600 Gbps per fiber cable [Ref. 20]. 


Fiber’s declining costs and distinct performance advantages, relative to the 
proposed available copper upgrade options (Category 6 and 7), make it appealing to large 
networks and the wiser choice when the time comes for an organization to install or 
upgrade the cabling infi-astructme. Already, companies, such as Western Integrated 
Networks and Optical Solutions, install fiber to the home and build broadband networks 
to the residential premises. 


B. QUALITY OF SERVICE IMPLEMENTATION 

As analyzed earlier, QoS mechanisms must be introduced to handle differentiated 
traffic and control resources of the network environment. Therefore, a robust QoS 


60 



scheme must be implemented to ensure proper service. Before appl 3 dng an extensive set 
of QoS policies and QoS-aware devices, it is necessary to identify the particular 
characteristics of the network (total required capacity, existing bottlenecks, traffic 
patterns) and the applications running on it. Furthermore, it is also important to determine 
what applications or users will be given priority, how the classification will be 
implemented and what mechanisms will be used to satisfy the requirements. 


The deployment of QoS mechanisms can be more effective with the 
implementation of the following: 

• Full adaptation of switched networks instead of shared and use of Virtual 
LAN (VLAN). 

• Multicasting, which intersects with QoS, allows the distribution of the 
same datagram to many destinations without replicating the stream 
multiple times. The implementation of multicasting results in increased 
network efficiency. To deliver IP multicast trafSc to the desktop 
efficiently, a solid-switched infrastructure is a necessity. 

• Caching and local mirroring, through the deployment of proper servers, 
constitutes another way of implementing effective traffic engineering and 
highly complements multicasting. Local access does not require the 
generation of additional traffic and the network is more responsive and 
interactive to the end user. 

• A non-hardware approach should involve the end-users. User training and 
discipline is imperative for the efficient use of the network. It is necessary 
to establish essential operational procedures, minimize wasteful ones and 
make users understand the existing bandwidth constraints. Bandwidth 
hungry applications, such as an online PowerPoint presentation, can be 
easily avoided with optional techniques that perform the same operation in 
a more efficient way (for example doing the presentation in HTML 
format). 
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QoS is too costly and complex to implement everywhere, and even the most 
robust QoS capabilities cannot overcome poor network design. Furthermore, it should be 
taken into consideration that many nodes on the network are folly satisfied with the 
current service they receive and do not require an additional QoS overhead to perform 
their operations. 


It becomes increasingly apparent that the wiring closets in campus networks and 
the backbone LAN-to-WAN aggregation points constitute the network performance 
bottlenecks. A typical campus network runs on switched Ethernet at 10/100 Mbps to the 
end hosts and close to 1 Gbps from the wiring closet to the backbone, either Gigabit 
Ethernet or ATM. Also, there are big bandwidth mismatches between LAN and WAN 
networks and it is usually the case that the aggregate LAN traffic destined to the WAN is 
greater than the WAN bandwidth capacity. A good example is the routers at the border of 
a military radio WAN that definitely requires additional intelligence to handle efficiently 
the limited resources. 


The model of combined DiffServ/IntServ or pure DiffServ is more appealing than 
IntServ because it preserves the connectionless nature of the network and keeps per-flow 
state out of the core network. As it was explained in the previous chapter, the DiffServ 
model improves the scalability of QoS provisioning by pushing state and complexity to 
the edges of the network and keeping classification and packet handling functions in the 
core network as simple as possible. The core devices only perform traffic handling and 
congestion control. With this approach, intelligence is applied primarily at the edge 
devices, where the network experiences the most severe bottlenecks, while the core 
devices remain simple and fast. Therefore, it makes the most sense to implement QoS as 
follows: 

• Classification and prioritization by the end systems (applications/users). 
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• Mapping, traffic shaping, policing and admission control by the edge 
network devices. 

• Traffic handling and congestion control by the core network devices. 

• Supervision and administration control by smart network devices 
(bandwidth brokers) whereby each of them overviews part of the network. 

1. Classification and Prioritization by End Systems 

Within a network, classification and prioritization is made by QoS-enabled 
applications that can dynamically signal their QoS requirements with several approaches. 
This can be achieved at layer 3 (IP), by setting properly the DSCP of the DiffServ field or 
sending RSVP messages, and at layer 2, by setting the 802. Ip bits of the MAC header. 


Despite the fact that prioritization schemes allow the usage of 8 (IP precedence, 
802.Ip) or 64 different service classes (DiffServ DSCP), the proposed QoS deployment 
specifies three service levels that categorize applications types, as shown in Figure 19. 
Improving user and application visibility by the network with the appropriate integration 
of policing, authentication and network management tools, will further allow to 
incorporate distinct user needs and privileges at the defined service levels. 


LEVELS 

TYPES OF APPLICATIONS 

EXAMPLES 

Level A 

Inelastic Intolerant Applications 

With low delay and jitter 

Interactive Voice Over IP 

Interactive Videoconference 

Critical Network Services 

Level B 

- Inelastic Tolerant Applications 

- Data Intolerant Applications 

Streaming Media 

Video on demand/TV 

Shared Interactive Data 
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Level C 

Elastic Tolerant Data 

File Transfer-Email- 


Applications 

Web browsing- Imaging 


Figure 19. Proposed Service Levels. 


This decision is made for the sake of 

• Flexible manageability. 

• Network device simplicity (need for configuration of three queues only). 

• Achieving end-to-end packet prioritization under heterogeneous 
internetworking, by smooth mapping among the existing QoS approaches 
of IP networks in LAN, campus backbones and WAN environments, 
shown in Figure 20. 


SERVICE 

LEVELS 

DIFFSERV 

INTSERV 

IP 

Precedence 

ATM 

802. IP 

A 

Expedited 

Forwarding 

Guaranteed 

Service 

4,5,7 

Constant Bit Rate 

Variable Bit Rate 

Real-Time 

6 

B 

Assured 

Forwarding 

Controlled 

Load Service 

3,6 

Variable Bit Rate 

Non Real Time 

3,4,5 

C 

Best Effort 

Best Effort 

0,1,2, 

Unspecified 

Bit Rate 

AvailableBit Rate 

0,1,2 


Figure 20. QoS Mappings For Defined Service Levels. 
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Adding network-wide QoS that can operate seamlessly across heterogeneous link- 
layer technologies and a variety of host platforms is complicated. Considering the 
difficulty of just ensuring the proper operation of the Current best effort IP-based 
network, it makes sense to introduce a small scale of traffic differentiation to the network. 
Limiting the number of DSCPs to 3, the number of PHBs is limited and consequently this 
mechanism allows for a large number of individual flows to be aggregated from the point 
of view of the core device. 


2. Functions Performed by Edge Devices 

The edge devices, implementing the PDP and PEP functionality in a single box, 
are configured to perform mapping to DiffServ (the backbone Layer 3 switches map 
802.1P prioritization to IP Precedence or DSCP, the edge routers map RSVP messages or 
IP Precedence to DSCP), traffic shaping, policing and admission control. In addition to 
the end hosts’ priorities, the edge devices can also associate the following fields as the 
basis for decisions; 

• Application TCP/UDP port number (layer 4) 

• Source/destination IP address (layer 3) 

• Date/ Time of the day 

Within an integrated policy-based network, proper network servers, dedicated to 
perform PDP’s control and decision-making operations, can imdertake part of the edge 
devices’ tasks. Furthermore, a final association can be made to entitled users with the 
proper use of authentication servers and directory services. 


The edge devices can be QoS-enhanced routers or other QoS-aware devices. 
Cisco Systems, who is the leading data networking company, has implemented in the 
latest versions of routers and switches most of the QoS techniques discussed in Chapter 
3. With Cisco Assure and Quality Manager, it offers a total policy-based solution that 
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supports dynamic QoS implementation. Other vendors, such as Nortel, Foundry, Extreme 
Networks and Juniper, have incorporated advanced QoS features in their products. 


Furthermore, there are several software and hardware products made by new 
companies that specialize in QoS, which are deployed at the edge of the network and 
provide an integrated solution for traffic conditioning and optimal use of network 
resources. They also optimize the performance of existing edge routers by offloading 
them of QoS processing overhead. Companies such as Sitara Networks, Packeteer and 
Allot Communications deliver QoS solutions through platforms that integrate highly 
scalable bandwidth management and end-to-end comprehensive QoS. These platforms 
are positioned into the network between WAN routers and LAN backbone switches, as 
shown in Figure 21, monitor and analyze real-time traffic and are capable of a broad set 
of point-solution functions: TCP rate-shaping, classification of IP precedence and 
DiffServ fields, all types of sophisticated queuing, packet-size optimization, dynamic 
allocation of bandwidth, HTTP caching and policy management. 

SITARA QOSWORKS 


WIDE AREA WAN ROUTER HUB OR 

NETWORK SWITCH 

Figure 21. Sitara QoS Integrated Solution. 

Policy management of devices can be achieved individually or by using a 
central policy manager that enables administrators to set global policies, as well as 
monitor, enforce and refine them dynamically. 

3. Incorporation of Bandwidth Brokers 

A scalable direction for dynamic provisioning and QoS implementation is to 
incorporate bilateral QoS-aware devices that will enable communication for exchanging 
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bandwidth requirements and QoS policy information between adjacent networks and 
domains. The concept of bandwidth brokers seems appropriate to fill that role. Each 
bandwidth broker, operating at a higher layer than PDF within a network, takes 
administrative control of a domain and controls how traffic flows through one’s network 
so as to optimize resource utilization and network performance. Bandwidth brokers peer 
to ask for and answer with admission control decisions for aggregates and exchange 
traffic. 


Adjacent domain bandwidth brokers negotiate in order to determine the nature 
and extent of traffic that will traverse across their common boundaries [Ref. 21]. As part 
of this process, each bandwidth broker describes its requested level of service to its 
neighbor’s bandwidth broker. The latter provides an admission decision based on its 
resource availability, bilateral arrangements as well as the set of administrative policies in 
effect. The decision is enforced by monitoring incoming flows into each domain. 


In general, a bandwidth broker may receive a resource allocation request either 
fi'om an element in the domain that the bandwidth broker controls, or a request from a 
peer (adjacent) bandwidth broker. In any case, the bandwidth broker responds to this 
request with a confirmation of service or denial of service. The request may have certain 
effects upon the network, such as altering the router configurations at the access inter¬ 
domain borders, and/or internally within the domain, and possibly generating additional 
messages requesting downstream resources. 

To illustrate the operation of bandwidth brokers practically, in Figure 22, suppose 
that an end user fi'om network A signals to bandwidth broker A that wants to have a 
videoconference with a user in network D. This signaling can be triggered either by 
explicit reservation or by proper prioritization of packets. Bandwidth broker A receives 
the request and checks whether it can handle this request through network B. Bandwidth 
broker B performs admission control based on whether there are sufficient premium 
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resources available, and whether the predefined agreements allow such requests. If the 
request is not admitted, i.e. network B does not have enough resources to accommodate 
the need for the videoconference, bandwidth broker A tries the path through C-D. If 
bandwidth brokers C and D agree, the request can be sent through A-C-D, instead of 
being rejected. The edge routers are being instructed by bandwidth brokers to allow the 
given traffic to flow through A-C-D. 


Bandwidth 
Broker A 


Bandwidth 
Broker B 


Bandwidth 

Broker#D 



Figure 22. Bandwidth Brokers Implementation. 


The concept of bandwidth brokers is very appealing, but has to be stabilized and 
fully standardized before being implemented. While it provides a sophisticated and 
scalable approach to resource management, the generated signaling overhead for the 
communication between bandwidth brokers must be taken into account. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


A. CURRENT STATE OF NETWORKS 

This thesis explored issues relating to the nature of voice and IP data networks, 
convergence, application demands, QoS, and bandwidth management that will shape 
networking architecture within an organization in the future. It took a holistic approach to 
the deployment of IP-based network of an organization that needs to support 
differentiated traffic of data, voice and video applications. 

The connection-oriented nature of the voice network and the support for relatively 
low bandwidth provided an optimal service for time-sensitive voice conversation, but it is 
not to provide high-speed digital access and accommodate the expansion of intensive data 
and video applications. The data network, founded on a connectionless packet-switching 
scheme, is based on the TCP/IP protocol suite that accomplishes a more robust ajid 
dynamic handling of resources. This IP-bjised network provides a best-effort service 
model for data applications, but falls short of delivering tight performance guarantees 
needed for delay-sensitive communication. 


The networking commimity, realizing the advantages of delivering data, voice and 
video over a single network infrastructure, has started to converge on the IP-based 
network that is the most convenient platform for the support of integrated traffic and has 
the potential to serve as the basis of a multiservice network. The gradual integration of 
voice and video in IP networks, the emergence of new applications and the increased 
sophistication of existing ones have forced the IP network to carry traffic with diverse 
requirements that all compete for network resources. 


To meet the traffic expectations, the IP-based network infrastructure must evolve 
and enhance its basic service model in many subtle ways, enabling the reliable and 
predictable service to differentiated network traffic. 
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B. RECCOMENDATIONS AND EXPECTATIONS FOR FUTURE 
NETWORKS 

This thesis proposed an organizational IP network infrastructure that can address 
the current demands and is flexible enough to support future requirements. Essentially, a 
balanced approach between broadband network capacity delivered at users’ doorsteps 
(through proper deployment of fiber cabling), and robust QoS implementation on the 
network will manage to accommodate current and future needs. 


Fiber cabling was proposed because it enables the greatest number of current and 
future value-added applications to the users. It is the fiber at the desktop that will 
revolutionize the capacity and will provide ample bandwidth. Additionally, QoS is 
essential to ensure sufficient performance and resource management. The proposed QoS 
implementation attempted to integrate and combine the advantages of the current QoS 
solutions. It determined the QoS functions to be performed as follows: 

• Classification and prioritization by the end systems (applications/users). 

• Mapping, traffic shaping, policing and admission control by the edge 
network devices. 

• Traffic handling and congestion control by the core network devices. 

• Supervision and administration control by smart network devices 
(bandwidth brokers) that each of them overviews part of the network. 

The intention was to affect minimally the connectionless and stateless nature of the IP 
infrastructure, and alleviate the concerns regarding the technical complexity, stability and 
scalability of QoS implementation. This implementation needs to be further tested 
practically and evaluated empirically. 


The introduction of QoS is especially important for organizations, such as the 
military, where there is an increased need for user differentiation and the extensive use of 
wireless and RF WANs makes overprovisioning much more difficult than terrestrial 
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infrastructure. The military organization should push aggressively towards the 
development of QoS and traffic engineering at the borders of the networks, in order to 
enhance the IP service model for advanced and guaranteed services. With all these in 
place, the ff-based network will be able to accommodate current and future needs of 
various applications and operate as a reliable multiservice convergent platform. 


There are still many research issues concerning the development and deployment 
of technology for a QoS-enabled IP infrastructure. Standards continuously evolve, but 
QoS has already been moved from an academic topic to an essential element of the 
network. The deployment of QoS mechanisms in IP networks is essential to allow control 
of various types of traffic, distinguish between several users and provide predictable and 
deterministic treatment of packet flows. As with any new technology, it will simply take 
time to evolve and mature. 

C. TOPICS FOR FURTHER RESEARCH 

As organizations gradually converge to a pure IP infrastructure, it becomes 
apparent that organizations will become more reliant upon a broadband, QoS-enabled and 
policy-aware network. Possible topics for further research include the following: 

• Design and implementation of a pure IP-based integrated campus network 
that could handle data, voice and video traffic, based on commercial 
solutions, such as CISCO AVVID solution and other networking 
companies. That could provide the test bed for a broader implementation 
in other military facilities. 

• Examination of the technical and economic issues surrounding the proper 
deployment of fiber optics close to the end users, at the campus network 
and at residential areas to subscriber users. 

• Implementation of an efficient multicasting file broadcast scheme, in 
combination with the introduction of caching servers in remote locations 
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that could sufficiently reduce the traffic demand and increase the 
information availability. 
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